home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000057_timbl _Wed Mar 4 10:42:32 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  6KB
  1. Return-Path: <timbl>
  2. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA17545; Wed, 4 Mar 92 10:42:32 GMT+0100
  4. Date: Wed, 4 Mar 92 10:42:32 GMT+0100
  5. From: timbl (Tim Berners-Lee)
  6. Message-Id: <9203040942.AA17545@ nxoc01.cern.ch >
  7. Received: by NeXT Mailer (1.62)
  8. To: jcurran@nnsc.nsf.net
  9. Subject: Re: Draft: Universal Document Identifiers
  10. Cc: cni-arch@uccvma.bitnet@nnsc.nsf.net, wais-talk@think.com,
  11.         www-talk@nxoc01.cern.ch
  12.  
  13. > Date: Thu, 27 Feb 92 19:45:42 -0500
  14. > From: jcurran@nnsc.nsf.net
  15.  
  16. >Even if the exact scheme is not used, the requirement
  17. > discussion contained in the paper is quite valuable.
  18. > I have a few comments:
  19. > 
  20.  
  21. >] Terms
  22. >]
  23. >] The objects on the network which are to be named include
  24. >] objects which can be retrieved, and objects which can be searched.
  25.  
  26. > Using this definition, one would infer that document identifiers
  27. > would allow reference to a distinct file, a particular mail
  28. > message, news article, etc. I would not anticipate that a document
  29. > identifier would be used to identify a newsgroup, interactive
  30. > service, archive directory , or a wais source.  Are  we trying to
  31. > define a universal id or a universal document id?  Might it be
  32. > better to defer the definition of non-document resources and then
  33. > come back and make the document specific id's be a subset of a
  34. > future general resource identifier?
  35.  
  36. You are right that the UDIs were inteneded to be able to refer to any  
  37. of those things. (In the W3 world, they all look pretty similar  
  38. anyway -- they are all represented as [hyper]text objects.)  It is  
  39. largely in order to be able to make references to any of those things  
  40. that we need a UDI rather than a WAIS-DI and a W3-DI and a news-DI  
  41. etc etc.  A UDI allows references between systems, and expandability  
  42. for the future.  My answer would be that we are trying to define a  
  43. universal document id, but where "document" has the very wide  
  44. interpretation as any data which can be retrieved, viewed or  
  45. searched: anything to which you might want to make a reference.
  46. For example, a person is not a document (although to have a document  
  47. on the net representing each person might be useful... their  
  48. signature/disclaimer with links to their published works, etc etc.)  
  49. If we can't cope with the objects which are on the net now, how can  
  50. we hope to cope with the wierd things to come .. video clips from the  
  51. news last night etc...
  52.  
  53.  
  54. ] Relevance
  55. ] 
  56.  
  57. ] The life of a name is limited by any information contained within  
  58. it which 
  59.  
  60. ] may become prematurely invalid. It is therefore necessary to limit  
  61. the 
  62.  
  63. ] contents of a name to the information required for the operations  
  64. above. 
  65.  
  66. ] Other extraneous information about the document (its size, data  
  67. format, 
  68.  
  69. ] authorization details, etc) may in general change with time and  
  70. should 
  71.  
  72. ] not be part of the name.
  73.  
  74. > The proposed document identifiers have many characteristics which 
  75.  
  76. > may change with time: storage location, access protocol, format, 
  77.  
  78. > etc. If we focus instead on the "information content" of a \
  79. > document, then it might be possible to form identifiers that are
  80. >  more robust.  Many people consider:
  81. >
  82. > file://info.cern.ch./pub/www/doc/udi1.ps      and 
  83.  
  84. > file://info.cern.ch./pub/www/doc/udi1.txt
  85. >
  86. > to be the same document; just in different formats.
  87.  
  88. Precisely. We look forward to the day when a name like
  89.  
  90.     x500:/CH/CERN/CN/TBL/TechNote-15
  91.  
  92. will be put through a name server which will return a set of  
  93. addresses. In the mean time, we don't have that ubiquitous name  
  94. server (directory) facility. So we have to make do with physical  
  95. addresses. And different versions of the same document look like  
  96. different documents. Its a shame. The plan is that UDIs can migrate  
  97. from physical addresses to registered names.
  98.  
  99.  
  100.  
  101. > It would be nice to be able to recognize this
  102. > and allow  the user (and user interface) to determine which
  103. > instance should be used for retreival.
  104.  
  105. Yes. Absolutely.  (The neatest way is for the client to send a set of  
  106. preferences over with the request, and for the server to decide which  
  107. to format to send. This is a suggestion for an evolved wais and/or  
  108. http protoccol.) Another way if for the client to ask a name server  
  109. for addresses, and retrieve the headers of each one to find out which  
  110. representation he'd prefer -- But I'd prefer all the represenattions  
  111. of the document to have the same name right down to the retrieval  
  112. protocol level.
  113.  
  114. > This recognition may only
  115. > be perform if the document id's (now being used document content
  116. > ids) contain only location and format independant data.  It is easy
  117. > to imagine that uniqueness could be assured by combining
  118. > an organization, author, and title:
  119. >
  120. >
  121. > cern.ch:www-staff:udi1 
  122.  
  123. >
  124. > ietf:osids:archdirectory-00 
  125.  
  126.  
  127. There are two functions: One, to find out whethre two documents are  
  128. the same. Two, to derive a (set of) addresses for retrieval of the  
  129. document. To be able to do the first, any unique id (like OSF/DCE  
  130. UUIDs or RFCxxxx message ids) will work. To be able to do the second,  
  131. a directory service is needed.
  132.  
  133. > Note that the actual location of the information might be far
  134. > removed from the point of creation, and the format might be
  135. > changed:
  136. >
  137. >cern.ch:www-staff:udi1;file://ftp.uu.net/doc/univeral-docids.PS.Z
  138. >cern.ch:www-staff:udi1;news:<1992Feb21.121919.1@quake.think.com>
  139. >cern.ch:www-staff:udi1;wais://nnsc.nsf.net/info-retrieval-notes?udi1
  140.  
  141. I see the usefulness of quoting both the unique identifier and the  
  142. physical address. I hope that in the future, though, one will only  
  143. need the first part "cern.ch:www-staff:udi1". That, fed into the  
  144. directory service, will produce a list of addresses.
  145.  
  146. You can, of course, still quote both: "You need document  
  147. x500:/cern.ch/www-staff/udi1 which I found on  
  148. file://ftp.uu.net/doc/univeral-docids.PS.Z".
  149.  
  150. I would also suggest that if a document has a unique registered name  
  151. then it should certainly contain that name, so that if you find it  
  152. some otherway, you can refer to it (make links to it) by its official  
  153. name.
  154.  
  155. > That's all
  156. > /John
  157.  
  158. Good points -- thanks for the input...I think more needs to go in  
  159. about registered unique names in the document.
  160.  
  161.     Tim BL
  162.  
  163.